docs(docsite): correct two stale backdropGlow comments left by #5415 - #5467
Merged
Conversation
The comment said a fixed glow below 1024px 'blocked pull-to-refresh from ever registering a release'. It never did — `overscroll-behavior-y: none` in globals.css did. The glow is the *reason that rule was written*: it was the layer bleeding into the bottom-overscroll gap, and bounding it is what lets the rule scope to desktop widths. Comment only, no behavior change. Follow-up to #5415 (issue #5392).
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
github-actions
Bot
requested review from
cvkxx,
ernestt,
kentonquatman and
rubyycheung
August 25, 2026 02:01
…eader comment The comment directly above backdropGlow still described the layer as 'fixed' full stop. Since #5415 that is only true at >=1024px; below that it is absolute inside heroScope. Same defect class as the comment this branch already corrects, four lines away. Both siblings state the split — HeroFloatingCards' stage says 'Hidden <1024px', page.tsx's heroContent says 'Desktop: fixed ... Narrow: in flow' — so this was the one layer comment that hid its responsive behavior. Comment only, no behavior change.
imdreamrunner
marked this pull request as ready for review
August 26, 2026 02:49
AKnassa
added a commit
to AKnassa/astryx
that referenced
this pull request
Aug 27, 2026
Contain the desktop-pinned hero layers so the app-global `overscroll-behavior-y: none` can be deleted outright instead of gated to desktop widths: macOS trackpads get their native rubber-band back. A `fixed` layer is not part of the document, so when the document rubber-bands past its own edge the layer sits in the exposed gap. A `sticky` layer lifts with the document and cannot paint past its containing block. Each pinned layer (aurora backdrop, overlap cards, hero text) now rides its own `absolute; inset: 0` rail, a direct child of heroScope spanning hero band + showcase and placed ahead of the showcase overlay, as a `position: sticky` box at >=1024px. Centering moves from `left: 50%` + `translateX(-50%)` to auto margins inside the full-width rail, and the 1200px box is capped to the rail's width rather than 100vw: with a classic scrollbar 100vw is wider than the rail, which zeroes the auto margins and shoves the box left. A rail inside the 760px band alone would release the layer after ~48px, which is why the rails span the showcase too. HeroReelProvider is context-only now; its hover/focus/touch surface is the new HeroReelSwipeArea, which page.tsx uses as the hero text's rail so the band still pauses the reel and the mobile collage still swipes. Also records on LayoutContent why `overflow: clip` must stay `clip`: `hidden` or `auto` there would silently un-pin the landing page. A source-invariant test (the docsite suite is node-only) guards the rule's absence, the three layers never going back to `fixed`, the rails' order and containment, and the AppShell/LayoutContent links that keep the main area a non-scroll container. Verified against untouched main with Playwright + pixelmatch at six viewports x ten scroll offsets: 0 px at the default threshold, identical layer geometry, `overscroll-behavior-y: auto` everywhere, no fixed element reaching the viewport bottom (was 2-3), 11/11 hover/focus/swipe checks passing on both trees, resize-while-scrolled and theme-swap mid-scroll 0 px. Safari and a real rubber-band are not verified here. Step 2 of facebook#5392. Fixes facebook#5470. Supersedes the zero-height-pin approach in facebook#5431 and folds in the backdropGlow comment correction from facebook#5467.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #5415 (issue #5392). Comments only — no behavior change, no CSS change.
#5415 made the hero's aurora glow responsive (
absolutebelow 1024px,fixedat and above it). Two comments on that same style object were left describing the old unconditional behavior. Both are corrected here.1. The causal chain was inverted
The comment added in #5415 says:
The glow never blocked pull-to-refresh.
overscroll-behavior-y: noneinglobals.cssdid — the glow is the reason that rule was written. The direction matters: the rule suppressed the whole page's overscroll to hide one bleeding layer, and bounding the layer is what let the rule retreat to desktop widths. As written, the comment sends the next person to the wrong file.2. The header comment still claimed the glow is unconditionally fixed
Four lines above, the comment introducing
backdropGlowopened with "Blurred aurora glow — fixed, …". Since #5415 that is only true at ≥1024px.Both sibling layers state their split —
HeroFloatingCards'sstagesays "Hidden <1024px",page.tsx'sheroContentsays "Desktop: fixed … Narrow: in flow" — so this was the one layer comment hiding its responsive behavior, and the first thing a reader hits.Risk
None. Ten comment lines in one file; no code, no styles.
Testing
prettier --checkandeslint --no-cacheclean on the changed file.check:changesetspasses — no changeset needed (docsite app code, not a published package, and nothing consumer-visible). CI was green on the first commit and covers the second.